home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 183 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. Path: solon.com!not-for-mail
  2. From: diamond@tko.dec.com (Norman Diamond)
  3. Newsgroups: comp.lang.c.moderated,comp.std.c
  4. Subject: Re: Function returning structure
  5. Followup-To: comp.std.c
  6. Date: 25 Jan 1996 06:34:13 -0600
  7. Organization: Digital Equipment Corporation Japan , Tokyo
  8. Sender: clc@solutions.solon.com
  9. Approved: clc@solutions.solon.com
  10. Message-ID: <4e7tc5$mk@solutions.solon.com>
  11. References: <4e2ki8$l0k@solutions.solon.com> <4e5p00$6g9@solutions.solon.com>
  12. Reply-To: diamond@jrdv04.enet.dec-j.co.jp (Norman Diamond)
  13. NNTP-Posting-Host: solutions.solon.com
  14.  
  15. In article <4e5p00$6g9@solutions.solon.com>, tanmoy@qcd.Lanl.GOV (Tanmoy Bhattacharya) writes:
  16. >In article <4e2ki8$l0k@solutions.solon.com> bnelson@netcom.com (Bob
  17. >Nelson) writes: 
  18. >>(It goes on to add -- in its example text -- that f().x
  19. >>is a valid postfix expression though not an lvalue, presuming that
  20. >>f is a function returning a structure and that x is member).
  21. >>With that in mind -- does the standard have anything that might
  22. >>disqualify member selection (in a non-assignment context) if that
  23. >>member is of type array and that structure is returned by a function?
  24.  
  25. >There is nothing wrong selecting that element. However, this element
  26. >does not decay to a pointer to its first element. As a result, very
  27. >few things can be done to it, except casting it to type void.
  28.  
  29. A perverse programmer could apply sizeof to it.
  30.  
  31. >Is the following strictly conformant?
  32. >  #include <stdio.h>
  33. >  #include <stdarg.h>
  34. >  typedef struct a {char b[5];} a;
  35. >  typedef char c[5];
  36. >  int f(char *fmt, ...) { char *s;
  37. >                          va_list ap;
  38. >                          va_start(ap,x); 
  39. >                          s = va_arg(ap, c);
  40.  
  41. I cannot find any reason that the returned result of va_arg would be an
  42. lvalue.  I believe that this example produces a non-lvalue array, which
  43. does not decay to a pointer and cannot be assigned to s.
  44.  
  45. >                          return printf(fmt,s); }
  46.  
  47. Mu.  But let's delete all mentions of s and printf, and try this instead:
  48.                            return some_other_vararg_f(fmt, va_arg(ap, c));
  49.  
  50. >i.e. can non-lvalue arrays be passed to a function and accessed by
  51. >the stdarg macros there?
  52.  
  53. I think that the standard permits it, and the standard needs to be fixed.
  54. ANSI Classic section 3.3.2.2, page 41 lines 33 to 35:  "In preparing for
  55. the call to a function, the arguments are evaluated, and each parameter is
  56. assigned the value of the corresponding argument."  Then some_other_vararg_f
  57. can use va_arg to get a copy of the thing, but there's still not much else
  58. that can be done with it.  I think the standard needs an additional
  59. constraint, that each argument shall have a type permitted for the right
  60. operand of a simple assignment.
  61. --
  62.  <<  If this were the company's opinion, I would not be allowed to post it.  >>
  63. "I paid money for this car, I pay taxes for vehicle registration and a driver's
  64. license, so I can drive in any lane I want, and no innocent victim gets to call
  65. the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
  66.